Currently, cellular and other MT users can subscribe to various location-aware services such as news, maps and local information provided by the wireless network. The wireless network tracks the movement of the MT to determine its location, or obtains the location from the MT if the MT has a Global Positioning System (GPS) receiver, and provides the user-specified content to the user based on the user's location.
There is currently a proposed mechanism for enabling service creation and management in regards to wireless networks. This mechanism in known as the Parlay Application Programming Interface (API), and is reviewed here as it provides a non-limiting example of a system that can be employed during the implementation of the teachings of this invention. The Parlay API has been developed by the Parlay group (www.parlay.org), an open, multi-vendor forum. The Parlay API has been accepted by the third generation partnership project (3GPP) for the Open Services Access (OSA) architecture of next generation cellular systems. The Parlay API is intended to provide an open, standard, technology-independent interface specification between applications and the wireless network functionality.
FIG. 1 shows a conceptual diagram of an application(s) server 1, possibly embodied as a WWW server, a Parlay API layer 2, and one or more underlying, possibly heterogenous wireless networks 3. For example, one of the networks 3 may be a circuit switched network (e.g., a Public Switched Telephone Network (PSTN) network or a Global System for Mobile Communication (GSM) network), while others of the networks 3 may be packet switched networks (e.g., one or more of a General Packet Radio System (GPRS) network, a Universal Mobile Telephone System (UMTS) network, a cdma2000 network or a WLAN communication network). The Parlay API layer 2 is intended to enable service portability across heterogenous networks. The Parlay API 2 provides a logical separation of service logic and network functionality, enabling customized third party services to be offered. A function of the Parlay API 2 is to hide the complexity of the target network(s) from the service logic and, by extension, the developers of the service logic. That is, a desired service can be developed to run on the application server 1 without regard for the specifics of the network 3. An important aspect of the Parlay API layer 2 is that it enables the service logic of the application 1 to use information and control capabilities of the networks 3, including network 3 call control, billing and MT location functions.
FIG. 2 is a more detailed view of the Parlay API 2 in the context of the OSA architecture. The application servers 1 are shown to include, by example, enterprise applications 1A and client applications 1B. Communication with the network 3 occurs through the Parlay APIs 2 over an administrative boundary 4. The network 3 is shown as including a network framework 5 and service capability servers (SCS) 6. The SCS 6 includes, by example, a call control server 7, a location server 8 and other servers 9. The framework 5 functions as a name server for the distributed network architecture, where available services, such as the call control 7, location 8, billing and so forth register their availability. The framework 5 serves as a first point of contact for consumers of the services, such as third party applications (e.g., the WWW server 1). A service consumer can discover the available services by querying the framework 5. The framework 5 also performs authentication of consumers and directs them to the actual service that resides in the SCS 6.The framework 5 may also accomplish performance-related tasks such as load balancing across different SCSs 6 offering the same service. The functionality provided by SCS 6 is referred to as the Service Capability Feature (SCF).
In the illustrated embodiment a first Parlay API 2 is available between the framework 5 and the client applications 1B, and is referred to for this example as an Authentication, Access Control and Service Discovery API. Second Parley APIs (SCF Usage) are available between the client applications 1B and the call control server 7, the location server 8 and the others server 9. A third Parley API 2 (Service Registrations, Integrity, Multi-Domain Support) is used between the framework 5 and the SCS 6. A fourth Parley API (Enterprise Application Subscription) is specified between the Enterprise Applications 1A and the framework 3, while a fifth Parley API 2 is defined between the Enterprise Applications 1A and the SCS 6, and is a counterpart to the second Parlay API when the consumer is the enterprise applications 1A. Normally the enterprise applications 1A engage in aggregate service contract with the network provider and maintain fine-grained control within themselves.
In the context of location-aware services, it should be noted that, at present, while the user is provided the option to subscribe to different services, the services themselves are not personalised. This is further explained below for the exemplary case that can arise during a cellular (e.g., GPRS or UMTS) to wireless local area network (WLAN) seamless inter-technology handoff.
In this case assume that the user's MT has two wireless RF interfaces, i.e., a cellular interface and a WLAN interface (e.g., a IEEE 802.11 or a Hyperlan interface). When the user runs an application, such as a voice over Internet Protocol (VoIP) call over the cellular network (for example while driving), the user typically desires to have the WLAN interface switched off for power saving purposes. However, when the user arrives at a certain location where the user can access a WLAN, such as the user's home or office, the user wishes to switch seamlessly (and automatically) to the WLAN. For this to occur the WLAN interface of the MT should be activated when the user comes close to the certain location where the WLAN is available so that the WLAN interface can begin scanning for the WLAN access point beacons, and can then register with the WLAN to enable the cellular/WLAN handoff to occur.
Prior to this invention, such highly personalized location-aware applications could not be realized with conventional wireless networks and MTs, with or without the use of the Parlay API.